Medical expandable platforms usually comprise complex hardware for examining patients, central and distributed hard disks for storing large volumes of data. Expandable medical platforms can be used both for managing medical patient data and for organizing clinic procedures, therapy planning, clinic management and the like, as are known to a person skilled in the art. Medical expandable platforms also comprise a multiplicity of nodes or clients which can access stored data, can initiate processes and possibly have access to complex hardware of a medical modality.
Modern medical modalities, such as magnetic resonance tomography (MR tomography), are characterized by the use of complex hardware appliances e.g. an MR scanner, and numerous complex processes, for example ranging from capture of the raw data through reconstruction of images of the inside of a patient's body to methods for diagnosis making and diagnosis support.
In a modern medical modality, the scanner has a real-time operating system. Such a real-time operating system ensures that the state of the scanner is determinate at any time. This means that the behavior of the processes in a real-time operating system, what are known as real-time processes, is known at any time. Besides real-time processes, such as the capture of raw data when examining a patient, there are a multiplicity of processes in connection with a medical modality which are not controlled by a real-time operating system and to a certain extent run in the background. This means that ideally they are not noticed by the user. These processes include the reconstruction of images from a 3D data record or, by way of example, the calculation of microcalcifications in the female breast for diagnosis support and therapy planning.
In contrast to the real-time processes which are executed on a scanner, for example, processes have to date been characterized in that the behavior of the processes is not deterministic. This means that in an expandable medical platform a multiplicity of processes are executed simultaneously. It may therefore arise that, by way of example, the writing of raw data to the hard disk of a scanner is slowed down considerably or, in the worst case, no longer possible at all if too many processes are running in parallel which simultaneously access the hard disk of the scanner. That is to say that a large number of I/O operations on the hard disk of a scanner can restrict the performance of the scanner, e.g. when scanning a patient.
A slower response by the scanner loses valuable time, e.g. when examining a heart attack patient. The small time window which remains for successful therapy on such a patient means that it is necessary to have a deterministic behavior for processes within the medical platform in order to provide for an assured quality of the services available within the expandable medical platform even in the event of a medical emergency.
Possible solutions to this problem are separate emergency systems, for example for making diagnoses, which are used exclusively for emergencies. Such a practice is expensive, since separate emergency systems normally need to be kept available unused. The high costs of an additional, separate emergency system are therefore not justified.
It would also be possible to allow none of the processes on clients which are required in the event of an emergency. Such a practice is likewise expensive, since further clients are necessary which exclusively perform the processes arising within the expandable medical platform. Furthermore, the increasing networking of all clients or nodes within an expandable medical platform (platform, for short) requires data to be able to be received and sent from all clients. For a platform client on which no processes are permitted, particularly no network access to this client or from this client to others would be possible.
To solve the problem described above, it would also be conceivable to use special operating systems for clients on which processes run. In this case, the special operating systems would need to assure a constant quality of service. Special operating systems of this kind are known to a person skilled in the art. However, the programming complexity for such quality of service systems is high, which means additional maintenance complexity, training times for the programmers, and also additional program translation operations for target systems, that is to say clients, running under the special operating system. In addition, there is an increase in the test complexity for the clients on which processes run under the special operating system.
It would also be conceivable to tie processes to selected dedicated CPUs. Although this would allow the availability of the CPU resource to be controlled, it still does not result in any influence on I/O activities taking place which have been initiated by processes. That is to say that the desired deterministic behavior for an emergency system would still not be assured.
It would also be possible to lower the priorities for processes. Such methods are normally provided by operating systems and are known to a person skilled in the art. Lowering the priorities for processes possibly has an adverse effect on the scheduling behavior of the entire client controlled by the operating system or the entire platform. However, an approach of this kind presupposes that every single process is implemented as a process at operating system level. With the large number of processes running within a platform, this approach is not very effective. Furthermore, changing the operating system priorities for processes in this way still does not mean a deterministic behavior in emergency situations.